AI disclosure: This PR was drafted with assistance from an AI coding agent (opencode + Claude). All code, tests, and docs were reviewed by a human before submission. Flagging this so reviewers can apply appropriate scrutiny.

Alternative proposal — see also #2869: This PR and #2869 solve the same problem with different API surface area. #2869 introduces richer headers.groups (named bundles with list, regex, or hybrid selectors) that subsume regex-only patterns. Either can land; they're not meant to ship together. This PR is the smaller, more focused primitive.

Why

Today, subgraph-specific header rules in the router are matched by exact subgraph name. Feature subgraphs are composed under their own name (e.g. products-feature-v2) rather than the base subgraph's name (products), so per-subgraph rules defined for the base subgraph do not apply to its feature variants. Only headers.all rules carry over automatically.

There are two existing options for handling header propagation to feature subgraphs:

1. Use headers.all. This applies the rule to every subgraph regardless of name, so feature subgraphs are covered. The trade-off is that the rule is also applied to every other subgraph in the graph — including subgraphs that have no need for the header. For users who treat subgraph header lists as an explicit allow-list (to avoid leaking headers to subgraphs that shouldn't see them, or to keep request-deduplication keys tight), this is broader than they want.

2. Add a separate headers.subgraphs.<feature-name> block for each feature subgraph. This works and is precise, but the rule has to be authored statically against each feature subgraph name. For workflows where feature subgraphs are short-lived or numerous (for example, per-branch or per-PR feature subgraphs), this means router config edits and a router redeploy each time a feature subgraph is created or renamed. Without hot reload, that affects all GraphQL traffic for what should be a localized change.

This PR adds an opt-in third option: regex selectors that target a group of subgraphs by name. A single rule can cover a base subgraph and its feature variants without listing each one.

What

A new ordered list headers.subgraph_patterns whose matching field is a Go regex evaluated against the subgraph name.

Schema example

Before — a rule under subgraphs.products only matches the literal name products:

headers:
  all:
    request:
      - op: propagate
        named: X-Request-Id

  subgraphs:
    products:
      request:
        - op: propagate
          named: X-Products-Auth   # never reaches products-feature-pr-123

After — a single pattern entry covers the base subgraph and every feature variant:

headers:
  all:
    request:
      - op: propagate
        named: X-Request-Id

  subgraphs:
    products:                       # exact-name rules still work, unchanged
      request:
        - op: propagate
          named: X-Products-Internal

  subgraph_patterns:
    - matching: "^products(-feature-.+)?$"
      request:
        - op: propagate
          named: X-Products-Auth    # applies to products and products-feature-*
      response:
        - op: propagate
          named: X-Products-Trace
          algorithm: last_write

negate_match: true is also supported, mirroring how it already works on header-name regexes:

  subgraph_patterns:
    - matching: "^internal-.+$"
      negate_match: true
      request:
        - op: propagate
          named: X-Public

Rule evaluation order

For each subgraph the router builds a header set in this order:

1. headers.all rules
2. headers.subgraph_patterns entries whose regex matches the subgraph name (in config order)
3. headers.subgraphs.<name> rules for the exact subgraph name

Exact-name rules apply last so they can still override a broader pattern rule (e.g. via op: set). This matches how the existing two layers compose today.

Backward compatibility

No breaking changes.

• subgraph_patterns is a new optional field. Configs without it behave identically to before.
• headers.subgraphs.<name> continues to match by exact name with no semantic change.
• No proto / router execution config changes — entirely router-local.
• A fast-path skips all pattern logic when subgraph_patterns is empty (hasAnyPatternRequestRules == false), so existing users see zero added work per request.

Performance

The hot path is BuildRequestHeaderForSubgraph, called per data source in the execution plan via SubgraphHeadersBuilder.

Concrete properties:

• Regexes compiled once at startup in NewHeaderPropagation, stored in subgraphPatternRegex []*regexp.Regexp. Invalid regexes fail router init rather than at request time.
• No ReDoS risk — Go's regexp uses RE2, which is linear-time and rejects backtracking constructs.
• No per-match allocations for typical subgraph names.
• For realistic configs (n ≤ 5, k ≤ 20, names ~30 chars) this adds <10 µs per request, well below surrounding planning cost.
• One non-critical optimization left out for reviewer discretion: the package-level SubgraphRules helper (called during engine factory init, not on the request path) re-compiles pattern regexes per call. Easy to share the pre-compiled regexes if reviewers prefer; left as-is to keep the diff focused.

Implementation summary

Validation

Locally on darwin/arm64 with Go 1.26.3:

go build ./...                          # clean
go vet ./core/... ./pkg/config/...      # clean
go test ./core/                         # PASS (incl. new TestBuildRequestHeaderForSubgraph_PatternRules,
                                        #               TestSubgraphRules_PatternsIncluded,
                                        #               TestApplyResponseHeaderRules_PatternRules)
go test ./pkg/config/                   # PASS (golden fixtures updated)

Notes for reviewers

• Happy to drop the PR or rework the API shape if you'd prefer a different surface (e.g. nesting under subgraphs: with a sigil instead of a separate top-level list). Wanted to keep it explicit and additive to avoid colliding with existing exact-name rules.
• Open question: should SubgraphRules share the pre-compiled regex slice with HeaderPropagation instead of recompiling? Easy follow-up; called out above.
• Alternative I considered and rejected: automatic inheritance from base subgraph to feature subgraph. Cleaner UX, but proto/wg/cosmo/node/v1/node.proto only carries Subgraph{id, name, routing_url}, so feature-subgraph → base-subgraph linkage would need execution-config changes and a clearer compatibility story. Regex selectors are router-local and additive.